Welcome

Coding Style: When do you own it?

Honey badgers don’t care.

As any experienced developer of firmware or software will attest (and probably some hardware designers too) coding style is only slightly safer then trying to eat a porcupine like our friend the honey badger, and yes I’m going there today. But unlike the honey badger I do it because I care.

Today’s topic is “When do you own the code?”, you’re working on from a coding style perspective. Some developers are more like the honey badger and don’t care about anyone else and simply state if I’m working on it then it will be in whatever style I dictate (whether that style was agreed to or not). Opposite is you never modify the style of the code you are working on. Certainly having conforming code improves efficiency so in the long run will result in better code and take less time to debug things, however if you piss off your client or the team you’re working you’ll get the opposite result. So, I take a more middle road, but what I hope you’ll agree is a more nuanced approach.

When deciding whether I own the style of a module I consider the following factors:

  1. Does the code conform to the coding style agreed to by the group that owns the code? Like any style guide it’ll be open to interpretation but typically if there is a coding style that is being followed does the code follow it. If not its fair game to change it.
  2. How much code are we looking at? Size matters as dealing with a module that’s only 400 lines is a world of difference to couple dozen modules with 10’s of thousands of lines of code. Generally, even if the old code doesn’t conform, I won’t change its style to the new style or to my own if the code base is large versus the amount of changes I’m proposing. Typically, if the new code is less then about 25% of a module (file) I’ll leave the old code alone.
  3. Does it work? If the old code works well or well enough and is really complex (think fragile) unless I’m begin asked to fix it I will leave it alone. Remember that even a modest code base of 10,000 lines can take a long time to debug if you make changes everywhere even if the changes are just for cosmetic as you’ll be moving things around and typos are certainly possible.
  4. How good is the old code style? If the old style is really good but doesn’t conform, I will be more likely to leave it alone. Good good style will be easy to ready and interpret and conforming code can be horrible to read. And by extension is the old code is terrible, particularly if they don’t consistently conform to any style, I’ll be much more open to changing the code.
  5. What does the contract say? If you are working for some, especially on contract you rarely have spare time to clean up code because invariable if you see messy non-conforming code its likely to have bugs and once you start digging in you’re likely to find some bugs and spend unexpected amount of time fixing it, and if you weren’t asked to your client or boss will likely frown on that “waste” of time even if it significantly improves the code. This is a tough one and it happened to me many times where the code style and the code it self was poorly written. If its in that gray area I typically ask even if I know the client will say no because it lets them know there’s a problem and if a problem occurs later it won’t be a surprise.

So those are the main considerations, but let’s say you have decided changes have to be done you have some options besides wholesale changing. You could simply add the new code conforming to the correct style if you’re adding new functions or methods. If you are changing existing functions you might change only the functions you modified. Those are some middle ground and each situation is a bit different but I think that covers the most likely reasons you’d own the old code and change its coding style.

At the other end I’ve also been in situations where the project/team doesn’t have any coding style but there’s a coherent coding style dominating the majority of the code (usually the work of one lead developer). In that case, if your changes are minor it might make sense to adopt the current defacto standard and “do as the Roman’s do while in Rome”.

Hope that helps some of you decide on a pragmatic approach when dealing with coding style being applied in your future or existing projects. Once you decide on a course of action you can then unleash the your inner honey badger to get the job done as quickly as possible. I’ll return to coding style specifics in the future as it ties into successful development practices, that’s all for now.